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ABSTRACT 

The James Webb Space Telescope (JWST) is part of a new generation of spacecraft acquiring large data volumes from 
remote regions in space. To support a mission such as the JWST, it is imperative that lessons learned from the 
development of previous missions such as the Hubble Space Telescope and the Earth Observing System mission set be 
applied throughout the development and operational lifecycles. One example of a key lesson that should be applied is 
that core components, such as the command and telemetry system and the project database, should be developed early, 
used throughout development and testing, and evolved into the operational system. The purpose of applying lessons 
learned is to reap benefits in programmatic or technical parameters such as risk reduction, end product quality, cost 
efficiency, and schedule optimization. In the cited example, the early development and use of the operational command 
and telemetry system as well as the establishment of the intended operational database will allow these components to be 
used by the developers of various spacecraft components such that development, testing, and operations will all use the 
same core components. This will reduce risk through the elimination of transitions between development and 
operational components and improve end product quality by extending the verification of those components through 
continual use. This paper will discuss key lessons learned that have been or are being applied to the JWST Ground 
Segment integration and test program. 
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1. INTRODUCTION 


The James Webb Space Telescope (JWST), as shown in Figure 1, is 
be placed in orbit at the second Lagrange point (L2) (see figure 2). 
It is designed to enable fundamental breakthroughs in our 
understanding of the formation and evolution of galaxies, stars, and 
planetary systems 1 with a five-year mission and ten-year design 
goal. The JWST is scheduled to launch in 2013 from Kourou, 
French Guiana aboard an Ariane 5 launch vehicle. The JWST is 
designated to succeed the Hubble Space Telescope (HST) and 
Spitzer as part of the National Aeronautics and Space 
Administration (NASA) Great Observatories program. It will be 
controlled out of the JWST Science and Operations Center 
(S&OC), located at the Space Telescope Science Institute in 
Baltimore, Maryland. 


a large, cryo-cooled, infrared-optimized telescope to 
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Figure 1 - Members of JWST team, 
shown with the full-scale mockup. 



During the development phase, the importance of operations in the mission lifecycle is sometimes not given sufficient 
priority in the decision making process. This can lead to higher operations costs and complexity in the long term when a 
more “operations friendly” design and implementation might have been achieved. The JWST project will extend over 
20 years from initiation of requirements definition and development to end-of-life. With a mission goal of 10 years of 
operations contributing significantly to this lifetime, operations efficiency and 
costs are a significant consideration. As such, the JWST Project has made a 
conscious decision to involve operations personnel from the beginning of 
development. JWST system engineers gathered in 1998 to look at various 
options, technologies, and industry trends to determine how to implement this 
objective. 


1.1 The Starting Point 

The JWST Ground Segment and Operations (GS&O) team actively reviewed 
past and current practices and issues from various NASA programs. This 
included large and small programs at the Goddard Space Flight Center as well 
as other NASA centers. This is an ongoing process that started with studies on 
the implementation of best practices and lessons learned. The JWST team had 
paid particular attention to the missions shown in Figures 3 through 6, such as 
HST, Spitzer, and the Earth Observation System (EOS), as well as the European Space Agency (ESA) Herschel-Plank 
mission which is also a L2 mission. As part of those lessons, to remove any ambiguity in interpreting requirements or 
defining joint integration and test (I&T) and operations items, interface control document (ICD) development began very 
early in the mission life cycle. 



Figure 2 - Lagrange Points. 
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Figure 4 - Herschel 
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Figure 3 - Spitzer 


Figure 5 - EOS Satellite Figure 6 - HST 


1.2 Where We Are Today 

The JWST project is currently in the hardware and software development phase, see Figure 7. The I&T of the various 



Figure 7 - JWST I&T 



elements is at the unit and component level. During the requirements definition and design phases, the JWST Project 
developed ICDs for the spacecraft, science instrument, and ground system elements. The JWST Project has also 
developed and deployed Science Instrument Test System (SITS) development and test units which contain both the 
Common Command and Telemetry System (CCTS) and the project database which contains command and telemetry 
definitions as well as all configured data utilized to control spacecraft components. The JWST Project supplied each 
science instrument and flight software developer and test group with the SITS units which provide the tools necessary to 
construct project database inputs, send commands, receive telemetry, provide loads, exercise dumps, format the science 
data, and control ground support equipment (GSE). Currently thirty-two such systems have been deployed at locations 
worldwide, all using the formats, protocols, and databases that will ultimately be used in the operational S&OC Flight 
Operations Subsystem (FOS). 


1.3 Where We Are Going 

The JWST launch readiness date is June 2013. By that date, the JWST Ground Segment will have been developed and 
tested, and operations personnel training will be completed. Ground Segment testing will include the full range of test 
levels from development-level testing to system testing, acceptance testing, mission operations testing and simulations 
through end-to-end testing. The Ground Segment will also participate in project-level I&T activities. These activities 
not only require the use of the CCTS and the project database, but the other systems that perform mission planning, 
flight and science operations, and data archive systems (see Figure 8). 
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Figure 8 - Ground Segment Development Phases 


2. LESSONS TO BE LEARNED 

As all programs begin, a key factor that drives the requirement and interface definitions is the experience of the project 
personnel; we all come with our own experiences, biases, and lessons learned from our past. While this experience base 
is invaluable, it is also limited by the experiences of the personnel involved. As such, it is important to ensure that the 
pool of applicable lessons learned has adequate breadth and depth. The JWST Project recognizes the importance of 
considering and applying lessons learned and has culled lessons learned from various sources, including the NASA and 
GSFC lessons learned databases and has made them easily accessible from the Project’s internal website. To achieve the 
technical and programmatic benefits of applying lessons learned, JWST GS&O personnel have brought their personal 








work experiences to bear, have reviewed and continue to review the JWST and GSFC Lessons Learned, and have met 
with other missions to gain additional insight. 

The culmination of this review and analysis of lessons learned has led to the adaptation of numerous lessons learned in 
the JWST Ground Segment I&T program and planning. Key among these lessons are (1) adopt standards and protocols, 
(2) develop core system components early, (3) decouple the project database from operations applications, (4) employ 
sufficient science data during testing, and (5) archive the data collected during I&T. Each of these lessons, their 
implementation, plans, and benefits are discussed in the following sections. 


3. JWST KEY I&T DECISIONS 

With the selection of prime contactor in 2000, the JWST Project began making major key decisions for I&T that would 
be carried forward to the eventual operational system. These key decisions are shown below as they relate to each of the 
lessons learned: 

1. Adopt standards and protocols: Use Consultative Committee for Space Data Systems (CCSDS) standards and 
institutional capabilities; use the formats and protocols that will be utilized during the mission to develop the 
interfaces between the command and telemetry system and the spacecraft simulator. 

2. Develop core system components early: Use the same command and telemetry system and project database 
during all phases of development, I&T and operations. 

3. Decouple the project database from operations applications, such as the command and telemetry system. 

4. Exercise science data during I&T: Process the science data during development and I&T the same way it will 
be done in operations. 

5. Archive the data collected during I&T: Archive system level I&T data at the control center for post-launch 
access. 


3.1 Adopt Standard Formats and Protocols 

The decision to adopt standards for JWST data functions allowed common formats and protocols to be documented and 
implemented early in the mission lifecycle. The formats and protocols are defined in JWST high-level ICDs and 
requirement documentation that assures the formats and protocols are flowed down to lower-level interfaces and 
maintained across systems. These formats and protocols were decided early in the development process, resulting in 
little to no impact to the various systems under development. 

Adoption of these standards reduced the risk to the operational system by allowing for the formats and protocols to be 
tested during the development and I&T phases of the JWST mission. Furthermore, development and test time between 
the I&T facilities, the S&OC, the communications network, and the spacecraft will be reduced since the CCSDS 
standards that were chosen are familiar to the entities involved. The use of the CCSDS standards also enabled reuse of 
some existing flight software code. Selecting the standards early in the process allowed for the early definition of 
interfaces, which then allows for early testing of interfaces. The significant CCSDS standards adopted by JWST are: 

CCSDS 201.0-B-3 CCSDS Telecommand Channel Service 

CCSDS 202.0-B-3 CCSDS Telecommand Data Routing Service 

CCSDS 202.1-B-2 CCSDS Telecommand Command Operation Procedures 

CCSDS 203.0-B-2 CCSDS Telecommand Data Management Service 

CCSDS 301.0-B-3 CCSDS Time Code Formats 

CCSDS 727.0-B-l CCSDS File Delivery Protocol (CFDP) 

CCSDS 701.0-B-3 CCSDS Advanced Orbiting Systems, Networks and Data Links 

CCSDS 101.0-B-6 CCSDS Telemetry Channel Coding 



CCSDS 660.0-B-l CCSDS Extensible Markup Language (XML) Telemetric and Command Exchange (XTCE) 


Examples of the how the above standards will be being utilized in the I&T and operations environments are listed below: 

1. Real-Time Data Downlink: CCSDS virtual channel packets with Reed-Solomon encoding, which provides 
guaranteed data delivery. 

2. Stored Data Downlink: CFDP Type 2, which provides guaranteed data delivery. 

3. Command Uplink: CCSDS Communications Operations Procedurel-1 (COP-1) and CFDP, which provides 
guaranteed data delivery. 

4. Project database: Coded in XML and transfer by CCSDS XTCE. 


In addition to using these standards, the JWST Project adopted a protocol defining the detailed bit and byte relationships 
for JWST data. These relationships are defined in the JWST Project configuration controlled documentation. Including 
this level of detail in the JWST documentation removes any ambiguity during the development of the flight software and 
ground system elements thereby avoiding potential rework. 


3.2 Develop Core System Components Early 

The JWST Ground Segment is primarily based on HST and EOS heritage and the lessons learned from these large-scale 
missions — with a significant departure that embodies the lesson of develop core system components early. Like most 
missions, the EOS Terra Project utilized different C&T systems for its I&T and operations phases. The original EOS 
Terra C&T system was replaced by Raytheon’s Eclipse commercial-off-the-shelf (COTS) system approximately one 
year prior to launch due to technical problems. Had a common C&T system been used from development through the 
I&T effort, the problems with the original system could have been discovered earlier and possibly mitigated. 

Learning from this experience, the JWST Project is using the Raytheon Eclipse system for instrument and subsystem 
software and hardware development, I&T activities and for mission operations. Also leveraging off the EOS experience 
base with the Eclipse product, the JWST Project has had the following enhancements made to Eclipse: a fast turnaround 
(in minutes) capability for database updates, storage of engineering data in a generic decommutated format and Web- 
based functionality for generic user interfaces. 

The core C&T system and database are currently being used in the spacecraft and instrument laboratories during the 
development phase. These systems can be considered “mini-Mission Operations Centers,” providing all the capabilities 
needed to command, monitor, and process data. Utilizing the same systems during development, I&T, and operations 
eliminates “throw out” knowledge of systems that could have been used in various phases and, perhaps more 
importantly, allows for input and buy-in from all teams early in the mission life cycle. The JWST Project is using the 
“Test-As-You-Fly, Fly- As- You Test” and “Test Early And Often” concepts to reduce flight operations development and 
testing as well as reducing risk. These concepts are enabled by using the same core system components throughout the 
lifecycle. Moreover, the JWST integration approach for the common C&T system is to incrementally deliver software 
builds based upon the user’s development schedules. This approach incorporates lessons learned and corrections into 
subsequent builds, provides design flexibility to accommodate changes and enhancements, and provides early integration 
of key capabilities. 

In addition to the early definition and development of the C&T system, the project database was defined before the 
selection of the prime contractor. The project database contains all configured data utilized to control the Observatory 
and its components. This includes command and telemetry definitions, command procedures, display pages, flight 
software loads, and other operational products. Early development and deployment of the project database has allowed a 
common understanding of database formats and rules to be facilitated among all users. The JWST Project developed 
tools to manage the database at a central location as well as a toolkit that has been deployed on standard desktop 
computers to all science instrument, flight software, and spacecraft hardware vendors. 



3.3 Decouple the Project Database from Operations Applications 

The project database is independent of any other development, I&T and operations systems (such as C&T, planning and 
scheduling, trending, simulators and automation). The JWST project database is developed in the Extensible Markup 
Language (XML) and is stored in a non-proprietary format in American Standard Code for Information Interchange 
(ASCII). The JWST project database ICD defines the XML tags, definitions and relationships between tags. This 
allows for any ground system element to ingest the database and convert the data to their own internal format. The 
JWST XML database also can be converted to the CCSDS XTCE standard, providing compliance with the international 
standard. This use of the XML has saved the JWST Project time in testing the new database, avoided costs associated 
with other COTS products, and provided ease of use throughout the lifecycle due XML’s self-describing features. 


3.4 Exercise Science Data During I&T 

The JWST Project has defined the ground system processing of the science data for each of the four JWST instruments 
prior to start of flight software and hardware development. Each instrument development team has been provided a 
common tool that converts the science data from the spacewire-based format in which the data is originally collected to 
the format in which the data is stored onboard on the solid state recorder (SSR). Once the data is in the SSR format, it is 
transformed to the Flexible Image Transport System (FITS) format (along with any necessary engineering data). These 
various formats are identical to what will be used on orbit, by the DSN and the Flight Operations Team (FOT). This 
allows the science instrument teams to have the same calibration tools for I&T and mission operations. 


3.5 Archive the Data Collected During I&T 

Throughout system and observatory level I&T testing, all data deemed significant will be collected and archived at the 
S&OC. This will allow for the quick comparison of test data with on-orbit data for troubleshooting and calibration 
activities. Users often underestimate the size of the data to be saved, and in general will want to save more than is 
needed, and when asked, will resist deleting anything. When engineering the system for storing the archived data, 
expandability, XML tagging of the data, and generic input formats will allow for any expansion that will need to occur. 
The key drivers for the development of the I&T data archive are: 

• Quick access to historical data, 

• Support of anomaly investigation and trending and calibration, 

• Correlation to operational data, 

• Online access to data and 

• Collection of input from developer sites through launch site testing. 

The archive of I&T data is enabled by the use of the common C&T system and the project database, which allows the 
same tools, and archive system to be used for development and operations. 


4. I&T APPROACHES RESULTING FROM LESSONS LEARNED 

Based on lessons learned, the JWST Project team will use the following approaches for integration and test of the 
Ground Segment: 

• Define the flight interfaces, project database structure, science data processing, load/dump formats, and generic 
engineering formats early in the development process. 

• Test early and often. 

• Test as you fly, fly as you test. 

• Integrate on incremental software builds, adding new capabilities with each build. 



• Verify that the S&OC is compliant with all ICDs. Perform integration and interface connectivity testing for each of 
the external elements. Ensure the resolution of all S&OC discrepancies and incorporate lessons learned for future 
integrations. 

• Roll lessons learned during I&T into the development of operational products and operations concepts. 

• Segregate the Ground Segment with ICDs between each element, allowing vendors to supply different components 
and keeping the total system open and adaptable. 

• Utilize a central, application independent, XML-based, CCSDS XTCE compliant project database to minimize cost. 

• Utilize open engineering and science data formats, defined in ICDs, to allow dissimilar systems used during I&T to 
have access to data without design impacts. 

• Utilize CCSDS CFDP to reduce the amount of processing needed at end user site. 

• Utilize web-based technologies for user displays to provide more flexibility, quicker development, and reduce long- 
term costs. 

• Evolve the common C&T and project database systems from development through I&T to operations to ensure 
mission success. 

• Utilize a modular approach to system development to allow technology upgrades to occur naturally. 


5. SUMMARY 

JWST Ground Segment development and I&T activities have employed numerous lessons learned to reduce risk, 
improve quality and optimize development schedules. Key among these lessons are (1) adoption of standards and 
protocols, (2) early development of core system components, (3) decoupling of the project database from operations 
applications, (4) exercise of science data during I&T, and (5) archive of the I&T data at the operations center. 
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